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Executive Summary 


Customer: NASA’s Launch Services Program (LSP), Ground Systems Development and 
Operations (GSDO), and Space Launch System (SLS) programs; and the National Weather 
Service in Melbourne, Florida (NWS MLB). 

Current LSP, GSDO, and SLS space vehicle operations are halted when wind speeds from 
specific directions exceed defined thresholds and when lightning is a threat. Strong winds and 
lightning are difficult parameters for the 45th Weather Squadron (45 WS) to forecast, yet are 
important in the protection of customer vehicle operations and the personnel that conduct them. 
A display of the low-level horizontal wind field to reveal areas of high winds or convergence 
would be a valuable tool for forecasters in assessing the timing of high winds, or convection 
initiation and subsequent lightning occurrence. This is especially important for areas where no 
weather observation platforms exist. Developing a dual-Doppler radar capability would provide 
such a display to assist forecasters in predicting high winds and convection initiation. The wind 
fields can also be used to initialize a local mesoscale numerical weather prediction model to 
help improve the model forecast winds, convection initiation, and other phenomena. 

The 45 WS and NWS MLB tasked the Applied Meteorology Unit (AMU) to develop a dual- 
Doppler wind field display using data from the 45th Space Wing radar, known as the Weather 
Surveillance Radar (WSR), NWS MLB Weather Surveillance Radar 1988 Doppler (KMLB), and 
the Orlando International Airport Terminal Doppler Weather Radar (KMCO). They also 
stipulated that the software used should be freely available. The AMU evaluated two software 
packages and, with concurrence from NWS MLB and the 45 WS, chose the Warning Decision 
Support System-Integrated Information (WDSS-II). 

The AMU collected data from two significant weather cases: a tornadic event on 14 April 
2013 and a severe wind and hail event on 12 February 2014. For the 14 April case, the data 
were from WSR and KMLB. For the 12 February case, the data were from KMCO and KMLB. 
The AMU installed WDSS-II on a Linux PC, then processed and quality controlled the radar data 
for display and analysis using WDSS-II tools. Because of issues with de-aliasing the WSR 
velocity field, the AMU did not use data from this radar in this study and only analyzed the 12 
February case. 

Merging the data to create the dual-Doppler analysis involved several steps. The AMU used 
instructions from the WDSS-II website and discussion forum to determine the correct tools to 
use for the analysis, and was successful in creating a merged reflectivity field, which was critical 
to the success of creating a merged velocity field. However, the AMU was unable to create a 
merged velocity field. The AMU researched the WDSS-II forum for discussions on similar 
issues, asked questions on the forum, and tested different options and values in the merger tool 
with no success. 

Developing a dual-Doppler wind field was the main goal of this task, but that was not 
accomplished. It could be an issue of not using the correct options or the correct value for the 
options used, or there could be issues with the radar data. There is a follow-on AMU task to 
install the operational version of WDSS-II in the NWS MLB office. This will provide more 
opportunities to try different options and input values in order to create a merged wind field from 
KMCO and KMLB. 
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1 Introduction 


Current Launch Services Program, Ground Systems Development and Operations, and 
Space Launch System space vehicle operations are halted when wind speeds from specific 
directions exceed defined thresholds and when lightning is a threat. Strong winds and lightning 
are difficult parameters for the 45th Weather Squadron (45 WS) to forecast, yet are important in 
the protection of customer vehicle operations and the personnel that conduct them. A display of 
the low-level horizontal wind field to reveal areas of high winds or convergence would be a 
valuable tool for forecasters in assessing the timing of high winds impacting operations, or 
convection initiation and subsequent lightning occurrence. This is especially important for areas 
where no weather observation platforms exist. Developing a dual-Doppler weather radar 
capability would provide such a display to assist forecasters in predicting high winds and 
convection initiation. The wind fields can also be used to initialize a local mesoscale numerical 
weather prediction model to help improve the model forecast winds, convection initiation, and 
other phenomena. Finally, data combined from multiple radars would lessen radar geometry 
problems such as the cone of silence and beam blockage. This display would aid in using 
ground processing and space launch resources more efficiently by stopping or starting work in a 
timelier manner. 

1.1 Previous Work 

A previous Applied Meteorology Unit (AMU) task (Huddleston 2012) investigated the 
technical, hardware, and software requirements necessary to create a dual-Doppler capability 
using the 45 Space Wing (45 SW) Radtec 43/250 and the National Weather Service in 
Melbourne, Florida (NWS MLB) Weather Surveillance Radar 1988-Doppler (WSR-88D) radars. 
The evaluation showed that the creation of a dual-Doppler capability using the existing 
operational radar systems was feasible. However, data security and cost considerations had to 
be taken into consideration in light of current budgetary constraints. 

NWS MLB also expressed interest in this task, and suggested including data from the 
Federal Aviation Administration Terminal Doppler Weather Radar (TDWR) at Orlando 
International Airport (MCO). In addition, in the event of a radar outage at one of the sites, the 
multi-radar algorithms would provide continuing coverage of the area through use of the data 
from the remaining operational radar sites. 

1.2 Current Work 

With the positive results in Huddleston (2012), the 45 WS and NWS MLB tasked the AMU to 
develop a dual-Doppler wind field display using data from the 45 SW radar, known as the 
Weather Surveillance Radar (WSR), NWS MLB WSR-88D (KMLB), and the MCO TDWR 
(KMCO). They also stipulated that the software used to derive the wind field over east-central 
Florida should be freely available. The AMU evaluated two software packages and, with 
concurrence from NWS MLB and the 45 WS, chose the Warning Decision Support System- 
Integrated Information (WDSS-II; www.cimms.ou.edu/~lakshman/WDSS2/index.shtml ). 


2 Radar Data and Analysis Tools 

The AMU collected data from the three local Doppler radars identified in section 1.2. The 
tools needed for the analysis included software and a computer with sufficient computing power 
and memory to run the software and store the input and output data. 

2.1 Radar Data 

As stated previously, data from three local Doppler radars were used in this task: KMLB, 
WSR located west of the Kennedy Space Center (KSC)/Cape Canaveral Air Force Station 
(CCAFS) area, and KMCO. Figure 1 shows the radar locations. 

Data from two significant weather events were collected for the analysis: 14 April 2013 and 
12 February 2014. During the evening of 14 April, two F-0 tornados, winds in excess of 50 kt, 
and 1-inch hail occurred in and surrounding Brevard County, Florida, which is in NWS MLB’s 
county warning area (CWA) and contains KSC/CCAFS. On 12 February, winds in excess of 50 
kt and quarter-size hail were reported in some central Florida locations beyond Brevard County, 
but near and within the CWA. 
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Figure 1. Google Earth image showing the locations of the MCO TDWR, 45 SW WSR, 
and NWS MLB WSR-88D. 


2.1.1 WSR-88D 

KMLB is a Doppler radar with dual-polarization technology. It is an S-band radar with a 10- 
cm wavelength. The beam width is 1° and gate spacing along the beam is 0.25 km. The WSR- 
88D uses several volume coverage patterns (VCPs), which are sets of elevation angles the 
radar goes through in a specific sequence. The choice of VCP depends on the weather 
conditions and is controlled by the operator. 
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Data for both severe weather events described in section 2.1 were downloaded from the 
National Climatic Data Center (NCDC). The files were in Level II format, which contain the base 
data values for reflectivity, mean radial velocity, and spectrum width, and the dual-pol data 
values for differential reflectivity, correlation coefficient, and differential phase. Each file contains 
a complete volume scan with data from all elevation angles in the VCP. On the days used in this 
task, KMLB was predominantly in VCP 12, which has 14 elevation angles and was designed for 
use during severe convective events. The angles associated with VCP 12 and the order in 
which they are scanned are shown in Table 1. The first three angles are scanned twice, first for 
reflectivity and then for velocity. It took approximately 4 min 40 sec to scan through the elevation 
angles in VCP 12. Level-ll format files can be processed by WDSS-II routines. 

2.1.2 WSR 

The 45 SW WSR is also a Doppler radar with dual-polarization technology. It is a C-band 
radar with a 5.3-cm wavelength. The beam width is 0.95° and gate spacing along the beam is 
0.25 km. The 45 SW VCP is based on recommendations from the AMU (Short 2008) and meets 
a 45 SW requirement for minimizing the vertical gaps between beams. It has 13 elevation 
angles that scan in an interleaving pattern, going through every other angle on the way up and 
down. It takes approximately 2 min 50 sec to scan through the elevation angles in the 45 SW 
VCP. This scan strategy provides the 45 WS forecasters with improved monitoring of 

• low-level convergence in the boundary layer that contributes to thunderstorm 
development; 

• the atmospheric electrification layer (+5 C to -20 C) for evaluating lightning launch 
commit criteria (LLCC) and predicting lightning onset; 

• the layer where convective cloud tops and anvil clouds typically occur (25-40,000 ft) for 
evaluating LLCC; and 

• thunderstorms approaching from the southwest due to the reduced cone of silence 
(Roeder and Short 2009). 

Data from the 14 April case were collected from this radar. The files were provided by Mr. 
McNamara of the 45 WS. WSR data are in Vaisala’s Sigmet Interactive Radar Information 
System (IRIS™) format, and the files contain the same base and dual-pol values as the WSR- 
88D Level II data. Each file contains data from one elevation angle. The VCP used during the 
14 April event was the system default. As a result of an ongoing software upgrade project, the 
VCP sometimes changed to the default setting when the system was changed to a baseline 
configuration. The forecasters and LWOs were sometimes unaware of this change unless they 
noticed something different on the display. Once noticed, they would make the change back to 
the 45 SW VCP. Maintenance and a baseline change had recently been done on the WSR in 
April 2013, causing the system default VCP to be used for this case. This will not be an issue 
once the software upgrade project is complete. Table 1 shows the elevation angles in the 45 
SW VCP and the elevation angles in the default VCP used in this data set in the order they are 
scanned. The IRIS files can be processed by WDSS-II algorithms. 

2.1.3 TDWR 

KMCO is a Doppler radar but does not have dual-polarization capability. Like the WSR, it is 
a C-band radar with a 5.3-cm wavelength. The beam width is 0.55° and gate spacing along the 
beam is 0.15 km. TDWR has two VCPs: VCP 90, called Monitor mode, and VCP 80, called 
Hazardous mode. The specific elevation angles for each VCP vary among TDWR sites, and are 
dependent on the range of the radar from the airport. Table 1 shows the angles in both VCPs for 
MCO. The VCP in use is chosen automatically by the TDWR software based on echo intensity, 


coverage, and range to the airport. It takes approximately six minutes to scan through the 
elevation angles in both VCPs. In VCP 90, the elevation angles are scanned sequentially from 
lowest to highest in a volume scan. In VCP 80, the lowest angle is scanned every minute and 
the upper angles are scanned in two sequences. 

Files for the 14 April case were sent to the AMU by Mr. Paul Biron of the FAA, but WDSS-II 
could not process the file format. WDSS-II does have algorithms that can process the files taken 
directly from the Supplemental Product Generator (SPG). TDWR data are archived on the SPG 
for eight days and then overwritten. Work on this task started well after the 14 April case, 
meaning files for that day were no longer available on the NWS MLB SPG. Therefore, data from 
the other severe weather case on 12 February were collected from the SPG located in the NWS 
MLB office by Mr. Blottman of NWS MLB. The MCO TDWR primarily used VCP 80 on 12 
February. 


Table 1. The VCPs used for KMLB, WSR, and KMCO during the 14 
April 2013 and 12 February 2014 case study time periods. For the 
WSR, the Default VCP was used on 14 April. The 45 SW VCP is 
included for completeness. 

KMLB 
VCP 12 

WSR 

Default 45 Sl/V 

KMCO 

VCP 90 VCP 80 

0.5 

0.2 

0.2 

0.3 

0.3 

0.5 

0.4 

2.2 

0.3 

0.3 

0.9 

3.2 

5.7 

1.0 

1.0 

0.9 

6.6 

8.9 

3.3 

3.3 

1.3 

10.9 

12.5 

6.1 

6.6 

1.3 

16.1 

17.6 

11.0 

0.3 

1.8 

22.4 

28.3 

15.9 

10.0 

2.4 

26.0 

22.0 

20.8 

13.4 

3.1 

19.1 

14.5 

25.7 

16.8 

4.0 

13.4 

10.6 

30.6 

0.3 

5.1 

8.6 

7.3 

35.5 

29.9 

6.4 

4.8 

4.0 

40.4 

60.0 

8.0 

1.8 

1.2 

45.3 

3.3 

10.0 



50.2 

0.3 

12.5 



55.1 

6.6 

15.6 



60.0 

10.0 

19.5 




13.4 





0.3 





16.8 





29.9 





60.0 





0.3 
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2.2 Analysis Tools: Software and Hardware 

The AMU considered two free software packages to conduct the analysis and determined 
the computing resources needed for each. 

2.2.1 Software 

Huddleston (2012) identified three software packages that can be used to create a dual- 
Doppler analysis: a set of programs from The National Center for Atmospheric Research 
(NCAR), WDSS-II, and an add-on product for the 45 SW’s IRIS software called NDOP. 
Vaisala’s cost for NDOP at the time of that study was $16,000. Since the AMU was tasked to 
find freely available software because the 45 SW and KSC Weather Office budgets did not allow 
for software purchase, NDOP was not considered for this task. However, it should remain a 
consideration should funds become available in the future. 

The NCAR radar processing programs can, among other capabilities, create dual- and multi- 
Doppler analyses ( https://wiki.ucar.edu/displav/rayqriddinq/Home ). This software was used in 
Dolan and Rutledge (2007) to create multi-Doppler analyses in real time. It is also used by 
researchers at the University of Alabama in Huntsville (Dr. Lawrence Carey, personal 
communication). Mr. Jay Miller, retired from NCAR, is the contact point for the software and 
stated that he is working on updating the software and creating tutorials. That update is 
ongoing. 

The WDSS-II package was developed jointly by the Cooperative Institute for Mesoscale 
Meteorological Studies (CIMMS) at the University of Oklahoma (OU) and the National Severe 
Storms Laboratory. It has several capabilities including routines to merge Doppler radar velocity 
data onto a grid. The version available for free download can only be used in research mode. A 
license is needed for the operational version, but the licensed version is free for the NWS. 
( www.cimms.ou.edu/~lakshman/WDSS2/index.shtml) . 

After considering the positives and negatives of each software package and consulting with 
NWS MLB, the AMU chose the research version of WDSS-II to conduct the analysis. The 
ongoing updates to the NCAR software and the multiple programs involved could make it 
difficult to work with. WDSS-II has other capabilities besides merging radar data and is in use at 
several NWS offices. 

2.2.2 Hardware 

Through contacting the developers and consulting the websites of the NCAR and WDSS-II 
software, the AMU learned that any PC running a current Linux operating system is sufficient to 
run either package. The AMU has a 64-bit PC that was configured for this purpose. It has dual 
2.4 GHz processors, 6 GB RAM and 1 TB of hard drive space. The freely available Linux 
Community Enterprise Operating System (CentOS) Release 6.4 was installed on the PC. This 
operating system (OS) is compatible with the RedHat Linux OS. 


3 WDSS-II Preparation 

This section will describe how to use WDSS-II for the dual-Doppler analyses, starting with a 
brief overview of how to set it up. Details are in the Appendix. Installing and running the WDSS- 
II software requires a working knowledge of the Linux OS. Anyone who wants to use this 
software package should get Linux training if not already knowledgeable. 

3.1 WDSS-II Setup 

The AMU accessed the WDSS-II package through a form on the website 
wvvw.cirrms.oj.edu / -~iaksiinian/WDSS2/dovv')iioac : .shi.rri; by choosing a build (Figure 2), 
providing an email address and clicking on the “OK” button. Once on the page, scroll down to 
“WDSS-II Download Request” to find the form. Based on the PC configuration described in 
section 2.2.2, the AMU chose the first configuration in the list. After clicking the “OK” button, an 
email from CIMMS will be sent to the address given containing a link to download the requested 
build. 


WDSS-II Download Request 

Thank you for your interest in WDSS-II. We collect this information so that we can present summaries to agencies that fund us. The 
information you provide will not be used to contact you in the future. If you wish to find out about new versions, please revisit this page. 

The latest research version of WDSS-II available was built on: 

2014-05-28 (May 2014) 

1 . Which of the following builds do you need? 

□ 64bit_RHEL6 

G Java Algorithms and API (all platforms) 

□ API Documentation (all platforms) 

J Linux VM with WDSS-II installed (username and password: wdssii; root password is root) 

□ Extend authorization of older version to 20 1 5 (ah platforms) 

□ 64bit_RHEL5 (from May 2014, and no longer updated) 

□ 32bit_RHEL5 (from December 2010, and no longer updated) 

B32bit_RHEL4 (from December 2009, and no longer updated) 

2. What is your email address? 

(OK) 

r igure 2. The form on the WDSS-II website used to get access to the software package. 

Installation and quick-start instructions are provided on the WDSS-II installation webpage 
( www.cimms.ou.edu/~lakshman/WDSS2/installation.shtml) . The AMU first set up the Linux 
environment variables specific to running WDSS, which can be found on the installation and 
quick-start website above. Next, the command Idd wg was executed. This displayed all the 
libraries needed to run WDSS-II graphics and which ones existed in the path. Only two graphics 
libraries were missing. Mr. Erik Magnuson, a system and software engineer with ENSCO, Inc., 
assisted in setting up the graphics with the appropriate drivers and libraries. After Mr. 
Magnuson’s assistance, the AMU executed the command wg in a terminal window to open the 
WDSS-II display with success. 

For setup details, go to the Download and Setup section in the Appendix. 
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3.2 WDSS-II Data Processing 

Once the display was working, the next step was to prepare data for the display. The data 
used and produced by WDSS-II tools are in netCDF format. Therefore, the data from all radars 
must first be converted to this format before creating and displaying radar products. Fortunately, 
WDSS-II has tools to process WSR-88D Level-ll, TDWR, and Sigmet IRIS data formats and 
convert them to netCDF format. A list of WDSS-II tools and details on their usage can be found 
on the tools webpage: www.cimms.ou.edu/~lakshman/WDSS2/algdoc.shtml . 

WSR-88D Level-ll files can be converted directly into netCDF format with the Idm2netcdf 
tool. The instructions to process Level-ll data are on the installation webpage (section 3.1) 
under the heading “Creating Netcdf Products from Level-ll files.” The AMU processed the KMLB 
data according to these instructions. 

Before processing the TDWR and Sigmet IRIS data, information on their locations and VCPs 
must be entered into specific configuration files so WDSS-II will process them correctly. The 
AMU added the location information for both radars in the WDSS-II configuration file 
“radarinfo.xml”, and created new VCP files for each. The next step was to convert the data to a 
format that could be processed by the Idm2netcdf tool. The AMU used the tools 
sigmetlngestor and tdwrLoglngest to do this conversion for the WSR and KMCO data, 
respectively, then ran Idm2netcdf on both output data sets to create netCDF files for working 
with and displaying the data in WDSS-II. The AMU then used WDSS-II tools to guality control 
(QC) the reflectivity data and de-alias the velocity data before further processing and display. 
For details on the options used with the data processing commands, read the Data Processing 
section in the Appendix. 

3.2.1 Reflectivity Data QC 

The AMU QC’d the KMLB and KMCO reflectivity data using the WDSS-II tool w2qcnn. It 
uses reflectivity, velocity, and spectrum width data gate-by-gate in a neural network to 
determine if a return is meteorological or not (Lackshmanan et al. 2007). The AMU ran this tool 
using the netCDF data output from the Idm2netcdf tool. The WSR data were not QC’d with 
w2qcnn because that radar software has an internal routine that QC’s the reflectivity data and 
outputs them separate files from the non-QC’d reflectivity data. For the case data in this study, 
very few reflectivity gates were removed during the QC processes, perhaps due to the fact that 
the time periods in the data sets contained mostly meteorological targets during the severe 
weather events. Details on the command using w2qcnn are in the Appendix under the 
Reflectivity QC subsection in the Data Display section. 

3.2.2 Velocity Data De-aliasing 

Doppler radars have a maximum unambiguous radial velocity called the Nyquist velocity. If 
the wind speeds exceed the Nyquist velocity, the direction will change from toward (away from) 
the radar to away from (toward) the radar, and the magnitude of the radial winds will change in 
increments of twice the Nyquist velocity. For example, if the Nyquist velocity is 30 ms -1 and the 
wind speed is 35 ms' 1 , 

Actual velocity toward the radar: -35 ms' 1 + 2*30 ms' 1 = 25 ms' 1 

Actual velocity away from the radar: 35 ms' 1 - 2*30 ms' 1 = -25 ms' 1 

In this case, actual velocities toward the radar will be displayed as away from the radar and vice 
versa. For stronger wind cases, the sign of the value indicating winds toward or away from the 
radar may not change, but the magnitude will be incorrect. Also, more than one multiple of 
2*Nyquist may be needed to reduce the velocity magnitude to a value with in the Nyquist 
velocity interval, ±30 ms' 1 in this example. 


The KMCO velocities are de-aliased within the TDWR system and output as separate files 
from the aliased velocities. Therefore, the AMU did not run WDSS-II de-alias tool for this data 
set. The KMLB and WSR velocities, however, have no such algorithm in their systems and 
required de-aliasing. 

3.2.2.1 KMLB 

The KMLB velocity data were de-aliased with an added option, -D, to the Idm2netcdf 
command. The use of this option is described further in the Appendix in the KMLB Data 
Processing subsection of the Data Processing section. 

Examples of aliased and de-aliased KMLB velocity data are shown in Figure 3a and b, 
respectively. In the color legend at the top of each image the cool colors to the left of the center 
gray block (0 kt) represent negative velocity values toward the radar and the warm colors to the 
right represent positive velocities away from the radar. The Nyquist velocity of -55.7 kt towards 
the radar occurs in the light purple region just left of the green, and 55.7 kt away from the radar 
occurs in the yellow area just right of the red. 

In the lower left of Figure 3a, aliased velocities are represented by the yellow and red values 
in the center of the area surrounded by the circle. Going from the left of this circle toward the 
right, velocities were toward the radar and increasing in magnitude from -50 to -55 kt 
represented by the colors changing from green to light purple. Continuing to move toward the 
right in the center of the circle, the values abruptly changed to 53 kt away from the radar in the 
yellow and 40 kt away from the radar in the red. If real, this would be an area of very strong 
convergence, but it is more likely indicative of a level with winds stronger than -55.7 kt toward 
the radar. Similar aliasing is in the area surrounded by the ellipse in the upper right, except the 
actual velocities in this case were away from the radar. The speeds increased to 55.7 kt going 
from the red to yellow, but changed to -53 kt toward the radar where the color changed to light 
purple in the center of the yellow area. Velocity aliasing is evident in other areas of the display 
as well. These two areas were chosen for demonstration. 

The results of the de-aliasing algorithm are shown in Figure 3b. In the circle, the velocities of 
53 to 40 kt away from the radar in yellow and red became velocities toward the radar of -58 to - 
71 kt represented by light to medium purple. The aliased velocities in the ellipse changed from 
around -53 kt toward the radar to 58 kt away from the radar. The new de-aliased values were 
more consistent with the surrounding velocities in both speed and direction. 
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Figure 3. KMLB 8.0° velocity at 0040 UTC on 15 April 2013, a) aliased velocity 
and b) de-aliased velocity. The locations of the WSR-88D and 45 SW WSR 
radars are shown by the yellow circles, and the circle and ellipse highlight 
locations of the aliased (a) and de-aliased (b) velocities. 










3. 2. 2. 2 WSR 


The WSR velocity data were de-aliased with the dealias2d tool. The use of this tool is 
described further in the Appendix Velocity De-aliasing subsection of the Data Processing 
section. 

Before the data were QC’d, Ms. Crawford noticed more aliasing in the velocity data than for 
KMLB. The Nyquist velocity for the WSR is 21.3 m/s, or 41.4 kt. This can be seen clearly in 
Figure 4a. The legend at the top of the image has the same colors and values in kt as in Figure 
3. The Nyquist velocity of -41.4 kt towards the radar occurs in the bright green region on the left, 
and 41 .4 kt away from the radar occurs in the bright red area on the right. The circle to the left of 
the WSR radar in Figure 4a is in an area of velocities toward the radar, and the two to the right 
of the WSR are in an area of velocities away from the radar. Velocity aliasing is evident in these 
three circles as well as other areas in the display. In all three circles, velocities between the 
red/green boundary change abruptly from 40 kt toward the radar in the red to -41 kt away from 
the radar in the green. 

The de-aliased velocities are shown in Figure 4b. The aliased velocities toward the radar in 
the circle to the left of WSR were changed from the aliased ~40 kt away from the radar to a de- 
aliased -84 kt toward the radar (purple). The correct de-aliased values should be in the range of 
-40 to -50 kt toward the radar. The velocities in the circle to the upper right of WSR experienced 
the same issue. Where the velocities toward the radar (green) should have been changed to 40 
to 45 kt away from the radar, they were actually changed to 84 to 87 kt away from the radar. In 
the circle below to the lower right of WSR, the velocities toward the radar should have been de- 
aliased to away from the radar, but were not. The AMU noted that the WDSS-II display stated 
the Nyquist velocity was 62.2 kt. Looking further into the netCDF files the Nyquist velocity was 
found to be 31.98 ms -1 , or 62.2 kt. It is clear when looking at the aliased velocities in Figure 4a 
that the Nyquist velocity should be 41 .4 kt. It is not clear how it came to be defined as 62.2 kt. 

It is clear that these incorrectly de-aliased velocities cannot be used to derive a dual-Doppler 
wind field as the result would be erroneous. Because of this issue, the AMU decided to put 
these data aside and work on creating a dual-Doppler analysis between the KMLB and KMCO 
radars. 
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Figure 4. WSR 10.9° velocity at 0040 UTC on 15 April 2013, a) aliased velocity 
and b) de-aliased velocity. The locations of the WSR-88D and 45 SW WSR 
radars are shown by the yellow circles, and the circles highlight locations of 
aliased (a) and de-aliased (b) velocities. 



3.3 WDSS-II Display 

The first-time the AMU opened the WDSS-II graphical user interface (GUI), it had a black 
screen with a gray control area at the bottom (Figure 5). It is through this control area that the 
data are displayed. The darker gray buttons on the left in the control area are the top-level 
functions for the display. The first step was to load radar data. The AMU did this by clicking the 
Sources tab on the left to access the options needed to load and display the processed radar 
data. To add data, the AMU clicked the Add... button in the Sources tab section. This 
displayed the dialog box in the center of the display area in Figure 5. The AMU clicked the 
Browse... button next to the URL text box in the New Source area at the bottom of the dialog 
box, navigated to the directory containing the prepared 12 February KMCO data, provided the 
name “Feb12-KMCO” for the data set in the Name text box, and then clicked the Add button at 
the bottom right of the dialog box. Using the default “AN” in the History text box loaded all the 
files in the directory. 

After several more steps, including loading a map background, the AMU displayed the 
KMCO data for the severe weather event on 12 February 2014, shown in Figure 6. A tab with 
the name provided for the data set appeared in the Sources tab section containing three 
columns: radar products on the left, available elevation angles in the middle, and scan times on 
the right. For this example, the AMU chose the product ReflQC, which is QC’d reflectivity, the 
0.3° elevation scan, and the initial time in the data set at 213527 UTC. Several data sets can be 
added through the Sources tab, with each having its own tab. 
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WG -- NSSL/CIMMS Warning Decision Support System -Integrated Information GUI 


File View Navigate Camera Options Products Map Help 



Remove All | 

Figure 5. The initial screen in WDSS-II when issuing the wg command in a terminal 
window. The processes used to load data are highlighted by red rectangles with red 
arrows showing the sequence to get the dialog box that allows the user to browse for the 
data directory. 




Figure 6. The WDSS-II GUI with data and map background displayed. The Sources 
section contains a tab named “Feb12-KMCO” with the choices of radar product (left 
column), elevation angle (middle column), and scan time (right column) for KMCO on 12 
February 2014. The highlighted items in each list determine what is displayed: the 0.3° 
QC’d reflectivity at 213527 UTC. 

The features in the Products tab, which is at the top left in the control area, allow the user 
to choose which radar product to display and to scroll through elevation angles and times of the 
displayed product. Figure 7 shows the Products tab contents for the same data as in Figure 6. 
The time, date, and elevation angle of the displayed data are shown at the top, choices to 
control what is displayed are under this on the left, a text box area with columns for the radar 
source and product is to the right of that, and controls for the elevation angle and time displayed 
are on the right. Multiple products can be chosen in the Sources tab to add in the Products tab 
text box. More details and examples are in the Data Display section of the Appendix. 
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WG — NSSL/CIMMS Warning Decision Support System -Integrated Information GUI 
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Figure 7. Same data as Figure 6, but showing the Products tab containing a list of the 
data sets that have been loaded for display and the controls for changing elevation 
angles and times. 



4 Data Merger in WDSS-II 

The goal of this task was to use data from two or more Doppler radars to create a three- 
dimensional (3-D) wind field over east-central Florida and the KSC/CCAFS area. Given the 
velocity de-aliasing issues identified with the WSR data in section 3. 2. 2. 2, the AMU used the 
KMLB and KMCO data as a proof-of-concept for the analysis. The method successful in 
merging the KMLB and KMCO data could be used later to merge the WSR data with either of 
the other two radars. 

The AMU researched the WDSS-II forum for how to merge data from two or more radars 
and found that the merging process takes several steps. First, a 3-D grid area must be created 
for the merge command to access. Next, a simulator tool is started that reads the processed 
data from two or more radars and reorders it according to time. The merger tool can then be 
started in another terminal window. This tool uses the output from the simulator as input, 
processes the data using the merging procedure described in Lakshmanan et al. (2006), and 
then outputs the merged data. 

4.1 Merger Grid 

The grid over which the merger takes place is defined by a northwest latitude/longitude 
(lat/lon) and grid top height, a southeast lat/lon and grid bottom height, and the horizontal and 
vertical grid spacing. The AMU first created the dual-Doppler lobes for KMCO and KMLB. The 
baseline, or distance, between the two radars is 38 NM (70.5 km), which is within the optimal 
range for conducting a dual-Doppler analysis as reported in Huddleston (2012). The northwest 
and southeast corner lat/lons of a box that encompassed both lobes, as shown in Figure 8, were 
used to define the merger grid corners. 

The WDSS-II tool createCache creates the gridded area and must be run for each radar in 
the analysis. It computes where the data from each radar should be inserted in the 3-D grid. The 
output is used by the merger tool described later. Using this tool for both radars, the AMU 
defined a grid with a northwest corner lat/lon of 29.5 N/82 W and top of 10 km, a southeast 
corner lat/lon of 27 N/80 W and bottom of 0 km, and grid spacing of 0.009x0.009 degrees 
horizontal and 0.5 km vertical. There are approximately 111 km per degree latitude and 
approximately 97-99 km per degree longitude at the latitudes in the grid. The horizontal grid 
spacing of 0.009 is roughly equal to 1 km in both dimensions, slightly shorter in the east-west 
dimension than north-south. This resolution can be changed depending on operational or 
numerical model needs. 

Details of how the AMU used the createCache tool are in the Data Merger Grid Setup 
section of the Appendix. 
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Figure 8. Google Earth image of the dual-Doppler lobes and associated 
merger grid outline for KMCO and KMLB. 


4.2 Reflectivity Merger 

According to information in the WDSS-ll forum, the velocity merger requires merged 
reflectivity data as input. Also, the mergers must be run separately when using archived data. 
Therefore, the AMU created the merged reflectivity data first. Note, however, that the reflectivity 
and velocity mergers will be run concurrently in the real-time WDSS-ll. 

For mergers, two tools must be run simultaneously in separate terminal windows: 
w2simulator and w2merger. The first, w2simulator, reorders the radar scans by time and 
writes them out, and then w2merger fuses the data from the multiple radars onto the defined 3- 
D lat/lon grid using the procedure in Lakshmanan (2006). The inputs to w2simulator are the 
files output by Idm2netcdf for all radars being merged, an output directory, and the beginning 
and ending time for the merger, if desired. The inputs to w2merger are the output files from 
w2simulator, an output directory, and several options related to merging reflectivity. The AMU 
followed these procedures and was successful in merging the reflectivities between KMCO and 
KMLB. Details on the inputs to the tools used by the AMU are in the Reflectivity Data Merger 
section of the Appendix. 

Figure 9 shows the reflectivity from the KMCO 0.3 degree elevation scan at 2316 UTC on 12 
February 2014. The location of each radar is surrounded by a yellow circle. Note the small cone 
of silence, the black circle inside the yellow circle, at the KMCO radar. Figure 10 shows the 
reflectivity from the KMLB 0.5 degree elevation scan at 2318 UTC, the closest KMLB scan in 



time to the KMCO scan in Fiqure 9. The cone of silence at the KMLB radar is larger than that of 
KMCO. 



r igure 9. The KMCO reflectivity at 2316 UTC 12 February 2014, 
elevation angle 0.3 degrees. The yellow circles show the locations 
of the KMCO and KMLB radars. 



Figure 10. As in Figure 9 but for KMLB reflectivity at 2318 UTC, 
elevation angle 0.5 degrees. 
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Figure 3 shows the merged reflectivities at 2316 UTC. Note the reflectivities over the cones 
of silence seen in Figure 9 and Figure 10. The resolution is coarser than for either radar, KMLB 
has a gate spacing of 0.25 km and KMCO has a gate spacing of 0.15 km. The grid can be 
changed in the createCache tool if higher resolution is desired, but the 1-km grid spacing may 
be more appropriate for the merged wind field, which is the ultimate goal of this task. 



Figure 11. The KMCO and KMLB merged reflectivity at 2316 UTC 
12 February 2014, height of 1 km. 


4.3 Velocity Merger 

The process to create merged velocities is similar to that for merged reflectivities with some 
differences in the inputs to the tools. The merged reflectivity must be created first as it is used 
as input to the velocity merger routine. The w2simulator tool is used to access the input data 
for the velocity merger, but it has the merged reflectivity as additional input. As with the 
reflectivities, the AMU started w2simulator first, and then started w2merger for the velocity 
merger in another terminal window. 

The inputs to w2simulator are the same files are the same files as for the reflectivity merger 
with the addition of the output from w2merger for reflectivity, an output directory, and the 
beginning and ending time for the merger, if desired. The inputs to w2merger are the output 
files from w2simulator, an output directory, and several options related to merging velocity. The 
AMU followed these procedures and was unsuccessful in creating a merged wind field with the 
KMCO and KMLB velocity data as shown in Figure 6 of Lakshmanan et al. (2006). Details on 
the inputs to the tools used by the AMU are in the Velocity Data Merger section of the Appendix. 
The AMU searched the WDSS-II forum for ideas on what input to use in w2simulator and 
w2merger, asked questions on the forum when those ideas did not work, searched the WDSS- 
II website for documentation on using the merger tool for velocity, and tried several 
configurations of input to the tool. 

Figure 12 shows the velocity from the KMCO 1.0 degree elevation scan at 2212 UTC on 12 
February 2014. The radar locations are indicated by yellow circles. Figure 13 shows the velocity 


from the KMLB 1.3 degree elevation scan at 2211 UTC, the closest KMLB scan in time and 
space to the KMCO scan in Figure 12. 



Figure 12. The KMCO velocity at 2212 UTC 12 February 2014, 
elevation angle 1.0 degrees. The yellow circles show the locations 
of the KMCO and KMLB radars. 



Figure 13. As in Figure 12, but for the KMLB velocity at 2211 
UTC, elevation angle 1.3 degrees. 


Figure 14 shows the 2211 UTC merged velocity field at 3 km. The text at the bottom of the 
image states that this is merged aliased velocity, but the AMU also used de-aliased velocity with 
the same results. The data field is uniformly purple, in the RF range of the scale at the top. The 
pattern of black concentric rings around KMCO is unique to this height and time, other heights 
and times exhibit different patterns of black rings and purple background. 
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Figure 14. The KMCO and KMLB merged velocity at 2211 UTC 
12 February 2014, height of 3 km. 


5 Conclusions 

The AMU was tasked by the 45 WS and NWS MLB to develop a dual-Doppler display using 
data from three local Doppler radars and freely available software to derive the wind field over 
east-central Florida and the KSC/CCAFS area. A display of the low-level horizontal wind field to 
reveal areas of high winds or convergence would be a valuable tool for forecasters in assessing 
the timing of high winds impacting operations, or convection initiation and subsequent lightning 
occurrence. This is especially important for areas where no weather observation platforms exist. 
The wind fields would also be used to initialize a local mesoscale numerical weather prediction 
model to help improve the model forecast winds, convection initiation, and other phenomena 
important to space launch operations and public safety. 

5.1 Summary 

The Doppler radars include WSR, KMLB, and KMCO and the chosen software is WDSS-II. 
The AMU collected data from two significant weather cases: a tornadic event on 14 April 2013 
and a severe wind and hail event on 12 February 2014. For the 14 April case, the data were 
from WSR and KMLB. For the 12 February case, the data were from KMCO and KMLB. The 
AMU installed WDSS-II on a Linux PC, then processed and QC’d the radar data for display and 
analysis using WDSS-II tools. Because of issues with de-aliasing the WSR velocity field, the 
AMU did not use data from this radar in this study and only analyzed the 12 February case. 

Merging the data to create the dual-Doppler analysis involved several steps. The first was to 
define the 3-D grid over which the analysis would take place and create grid files that the 
merger tools could access. The merger itself required that a simulator tool be run in the 
background to access the data from both radars, reorder it according to time, then create output 
for the merger tool to access. The AMU ran the simulator and merger tools in separate terminal 
windows according to WDSS-II instructions, creating the merged reflectivity first as those data 
are needed as input for the velocity merger. For the archived data in this task, the 
simulator/merger tool combination had to be run separately for the reflectivity and velocity 
mergers. In real-time operations, one instance of the simulation tool will run in the background 
for both mergers, all taking place in separate terminal windows. 

The AMU was successful in creating a merged reflectivity field, which was critical to the 
success of creating a merged velocity field. However, the AMU was unable to replicate the 
results in Lakshmanan (2006) for a merged velocity field with wind barbs. The AMU researched 
the WDSS-II forum for discussions on similar issues, asked questions on the forum, and tested 
different options and values in the merger tool with no success. 

5.2 Using WDSS-II 

Installing and running the WDSS-II software requires a working knowledge of the Linux OS. 
Anyone who wants to use this software package should get Linux training if not already 
knowledgeable. To learn how to install and run WDSS-II and run the tools, the AMU consulted 
resources on the WDSS-II website, http://www.cimms.ou.edu/~lakshman/WDSS2/ , including 

• discussion forum ( http://forum.nssl.noaa.qov/viewforum.php?f=1 ), 

• training modules ( http://www.cimms.ou.edu/~lakshman/WDSS2/w2traininq.shtml ), 

• tools ( http://www.cimms.ou.edu/~lakshman/WDSS2/alqdoc.shtml ), 

• scientific articles ( http://www.cimms.ou.edu/~lakshman/WDSS2/papers.shtml) , and 

• other links found on the WDSS-II home page in the left column (Figure 15). 
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Warning Decision Support System — Integrated Information 

Automated algorithms, tools and displays for analysis, diagnosis and forecasts of severe weather phenomena www wdssn org 


WDSS-II 

Real-time Data 


The Warning Decision Support System — Integrated Information (WDSS-II) is the second generation of a suite of algorithms and displays for severe 
weather analysis, warnings and forecasting. WDSS-II has been developed jointly by engineers and scientists at the National Severe Storms Laboratory 
(NSSL) and the Cooperative Institute for Mesoscale Meteorological Studies (CIMMS) at the University of Oklahoma. 


o CONUS images 
o Google Earth 
o Google Maps 
o NWS LDM feed 

Discussion Forum 
WDSS-II Blog 

Documentation 

o Installation Quick start 
° Platforms 
o Display 
o Tools 
o Data Format 
o Real-ti m e. Monitorin g 
o Servmg out via LDM 
o Serving out via http 
o Training Modules 
o Scientific articles 
o FAQ 


WDSS-II has three components: 

1 . A suite of multi-sensor automated weather algorithms 
mcludmg techniques for combining and interrogating 
radar data, diagnosing hail, lightning and 
precipitation. 

2. A 3D earth and time-centered display for viewing 
multi-sensor data and algorithm outputs. 

3. An application programming interface (API) library 
in Ch — that supports algorithm and display 
developers. 


Please follow the links on the left to learn more about 
WDSS-II. 



o WDSS-II links 


Interrogating the 3D structure of a hurricane using the 4D , interactive 
display. The 3D structure (at 1 km resolution every' 5 minutes) was 
created in real-time by combining high-resolution radar data. 


-igure 15. The top portion of the WDSS-II home page. The links with information on how to 
install and use WDSS-II are in the left column under the Documentation link. 


The discussion forum was the most helpful of all the resources. To post questions, the AMU 
had to register and receive a username and password from the moderator. Searching the 
discussion database does not require login. The training modules were helpful, but several have 
out of date information and others are more focused on the network at OU. The documentation 
for the tools was limited. Each option is explained, but many explanations require more in-depth 
knowledge of the system to fully understand them. The scientific articles do not go into detail on 
how to use WDSS-II, but they provide good information about the science behind the system 
and how it can be used. The AMU did not find resources outside of the WDSS-II website with 
detailed explanations on how to use the system. 


5.3 Recommended Future Work 

Developing a dual-Doppler wind field was the main goal of this task, but that was not 
accomplished. It could be an issue of not using the correct options or the correct value for the 
options used, or there could be issues with the radar data. 

The AMU is presenting the results of this task at the National Weather Association 39th 
Annual Meeting in October 2014. There could be other WDSS-II users present that could 
provide assistance in conducting this analysis. Since WDSS-II functionality favors WSR-88D 
radars, perhaps a merger between two of these radars could be tested to see if a velocity field 
can be produced. The baseline between WSR-88Ds is too large for a meaningful analysis, but if 
it works it would show that the issue is with the KMCO radar data. The AMU could then focus on 
the radar data and determine how it needs to be modified to produce a successful merged wind 
field. Finally, there is a follow-on AMU task to install the operational version of WDSS-II in the 
NWS MLB office. This will provide more opportunities to try different options and input values in 
order to create a merged wind field from KMCO and KMLB. 



Appendix: WDSS-II Setup and Use Details 
Download and Setup (Section 3.1) 

The download instructions for the WDSS-II software package are in section 3.1, which is a 
.tgz file. Specific and easy-to-follow instructions for installing WDSS-II with this file are on the 
webpage www.cimms.ou.edu/~lakshman/WDSS2/installation.shtml under the title “Installation” 
near the top of the page. There are also instructions for setting the environment variables in the 
.bashrc file that exists in the home directory on a PC with a Linux OS. The final version of the 
.bashrc file is in Figure . 



wcrawford@doppler:~ 

_ □ X 

1 file 

Edit View Search Terminal Help 
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Q .bashrc 

# Source global definitions 
if [ -f /etc/bashrc ]; then 

. /etc/bashrc 
fi 

# User specific aliases and functions 

export LD_LIBRARY_PATH=/home/wcrawford/WDSS2/lib : SLD LIBRARYPATH 
export PATH=/home/wcrawford/WDSS2/bin : SPATH 

export W2 C0NFIG_L0CATI0N=/home/wcrawford/w2config :/home/wcrawford/WDSS2/w2config 
export UDUNITS PATH=/home/wcrawford/WDSS2/etc/udunits .dat 
export RMTPORT=50000 

export LD_LIBRARY_PATH=/usr/local/lib:SLD_LIBRARY PATH 
export LIBGL_DEBUG=verbose 


-igure 1 . Content of the .bashrc file. 

To get the missing graphics libraries, type “yum provides */libgtkglext*” to search for the 
appropriate library files. Once found, use “yum install <librarypackagename>” to install the 
libraries. Once installed, type “wg” in a terminal window to open the WDSS-II display. If there is 
an error, it is likely the graphics driver. For the AMU PC, Mr. Magnuson had to update the Linux 
kernel, disable the nouveau graphics driver, and install the Nvidia graphics driver in order for the 
WDSS-II display to work. 

Data Processing (Section 3.2) 

The data files collected from the radars needed to be processed and converted to netCDF, 
the format used by WDSS-II. Descriptions of the tools to do this and other analyses in WDSS-II 
are on the Tools webpage: www.cimms.ou.edu/~lakshman/WDSS2/alqdoc.shtml . 

KMLB Data Processing 

The AMU converted the KMLB data directly into netCDF format using the command 

Idm2netcdf -i <input directory> -o <output directory> -s KMLB -p 2014 -a -1 -D --verbose 
where 

• <input directory> is the full pathname of the directory containing the Level-ll data, 

• <output directory> is the desired directory for the output, which must exist beforehand, 

• -s identifies the four-letter station name, 

• -p identifies a pattern common in all filenames that need to be processed, 
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• -a takes no arguments and indicates the archived files will be read on startup, 

• -1 takes no arguments and indicates the program will run only once since it is not 
operating in real time, 

• -D de-aliases the velocity data, and 

• --verbose outputs verbose debugging information. 

This command works for WSR-88D data that have been archived at NCDC. For data collected 
directly from the local radar system, add the -L option to the Idm2netcdf command line. This 
option allows the command to read data files that are zipped radial-by-radial. 

The de-aliasing algorithm will work more accurately if a file containing a vertical profile of the 
winds observed near or during the radar data period is available for Idm2netcdf. The user 
creates this file for each case using sounding or profiler data available at the time. The name of 
the file must be “input. snd” and must be in the same directory in which Idm2netcdf is executed. 
The first line contains the number of data levels in input. snd, the second line contains the height 
of the radar in feet, and the following lines contain the observations with height in feet and 
1,000-ft intervals, direction in degrees, and speed in knots as in the example for the 15 April 
2013 case and KMLB: 


59 



120 



1000 
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20 

2000 

178 

17 

3000 

184 

17 

6000 
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18 

7000 

205 

17 

61000 
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These data were from the 915- and 50-MHz profilers since no sounding was available on 15 
April. In this case, there were 59 data levels with two missing at 4,000 and 5,000 ft. The 
program interpolates through these missing data points and outputs a file named “ewt_table” 
containing the wind speeds converted to ms -1 and separated into u and v components. The de- 
aliasing algorithm will use these data as a first-guess wind profile. 

KMCO and WSR Location Information 

The AMU had to prepare configuration files before running the algorithms to process the 
KMCO and WSR data files. The first step was to enter the location information for both radars in 
WDSS-ll’s radarinfo.xml file. This file can be found in the directory 

/home/. . ./WDSS2/w2config/misc 

where is the user’s directory. The site information for KMLB is in the original file provided 
with WDSS-II. At a minimum, the entries include the radar name, a user-supplied site name, 
latitude and longitude location, and height of the radome above sea level in meters. The AMU 
entered the information for the WSR in the “Military Radars” section as 

<radar name="PAF" site="Eastern Range"> 

location lat="28.3938" lon="-80.9509" ht="47.97> 

</radar> 

TDWR information also requires the magnetic offset and the radar frequency. The AMU entered 
the information for KMCO in the “TDWR for FAA Tech Center” section as 


<radar name="MCO" site="Orlando International" magnetic_offset="6W" frequency="5640"> 
<location lat="28.3437" lon="-81.3257" ht="51.5"/» 

</radar> 

The magnetic offset changes slowly over time and should be checked and updated when 
needed. The AMU used the website http://magnetic-declination.com/ to get the value for 
Orlando. The magnetic offset option in the file does not take decimals, so the AMU rounded the 
value, which is currently 6.1° west. 

KMCO and WSR VCP Files 

Files for the WSR-88D VCPs came with the WDSS-II build, but there were none for KMCO 
or WSR. Therefore, the AMU created one file each for the default WSR VCP, and the two 
KMCO VCPs shown in Table 1. The WSR VCP file is named vcp4513 and the two KMCO VCP 
files are named vcp203 and vcp204 for VCP90 (Monitor) and VCP80 (Hazardous), respectively. 
Each file contains some header information, then a list of the elevation angles in the order they 
are scanned. The first element is the VCP number, the next is a logical statement of whether the 
radar is a WSR-88D followed by another logical statement of whether it is a clear-air VCP, the 
final is the time in seconds to go through a complete volume scan. The following text is the 
summarized content of the vcp4513 file showing the header, first and last elevation angles, and 
“...” representing the intermediary angles. 

<vcp number="4513" isNexrad="false" isClearAir="false" totaltime="170"> 
<angle>0.20</angle> 

<angle>1 .80</angle> 

</vcp> 

The TDWR VCPs have an extra logical element, named “canCache”, indicating whether a radar 
can change its VCP quickly. It is true for the TDWRs. The following two text groups are the 
summarized content of vcp203 and vcp204, respectively, showing the header, first and last 
elevation angles, and representing the intermediary angles. 

<vcp number="203" isNexrad="false" isClearAir="true" canCache="true" totaltime="360"> 
<angle>0.3</angle> 

<angle>60.0</angle> 

</vcp> 

<vcp number="204" isNexrad="false" isClearAir="false" canCache="true" totaltime="360"> 
<angle>0.3</angle> 

<angle>0.3</angle> 

</vcp> 

The AMU will provide these files to NWS MLB for the follow-on task. 

WSR Data Processing 

The AMU processed the WSR data using the command 

sigmetlngestor -i <input directory> -o <output directory -s PAF -p PAF -a -1 -b 1 -v 4513 -k 
where 

• <input directory> is the full pathname of the directory containing the Level-ll data, 

• <output directory> is the desired directory for the output, which must exist beforehand, 
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• -s is the four-letter station name, 

• -p is a pattern common in all filenames that need to be processed, 

• -a takes no arguments and indicates the existing archived files will be read on startup, 

• -1 takes no arguments and indicates the program will run only once since it is not 
operating in real time, 

• -b designates the beamwidth of 1 ° for the WSR, 

• -v specifies the VCP number to use, and 

• -k will stop the algorithm from deleting the archived files. 

The data in the output directory were in the format needed for ingest into Idm2netcdf. The 
AMU then converted the sigmetlngestor output to netCDF format using the command 

Idm2netcdf i <input directory> -o <output directory -s PAF -p PAF -a -1 -verbose 

where the input directory is the output directory for the sigmentlngestor command, and the 
output directory must exist beforehand. The options are the same as in the Idm2netcdf 
command for the KMLB data except for the -D de-alias option. The reasoning for excluding -D 
is explained in the main text. 

KMCO Data Processing 

The AMU processed the KMCO data using the command 

tdwrLoglngest -i <input directory> -o <output directory -s MCO -p .log 

where 

• <input directory> is the full pathname of the directory containing the Level-ll data, 

• <output directory> is the desired directory for the output, which must exist beforehand, 

• -s is the radar name, 

• -p is a pattern common in all filenames that need to be processed, 

The data in the output directory were in the format needed for ingest into Idm2netcdf. The 
AMU then converted the tdwrLoglngest output to netCDF format using the command 

Idm2netcdf i <input directory> -o <output directory -s MCO -p MCO -a -1 -verbose 

where the input directory is the output directory for the tdwrLoglngest command, and the output 
directory must exist beforehand. The options are the same as in the Idm2netcdf command for 
the KMLB data except for the -D de-alias option. The reasoning for excluding -D is explained in 
the main text. 

Convert Idm2netcdf Output 

The Idm2netcdf tool produces directories for every radar parameter and a directory named 
“codejndex.fam” that is used as input (-i) to other tools and the GUI. The WDSS-II tools 
assume that this directory, and all directories with the *.fam extenstion, represents real-time 
data and will not exit upon completion. It must be converted to an xml file that WDSS-II will 
recognize as archived data. To convert the codejndex.fam directory to an xml file, the AMU 
used the tool replacelndex in the following command: 

replacelndex -i <home/.../codeJndex.fam> -o <home/... /output codeJndex.xml> 


where 


• <home/.../code_index.fam> includes the full pathname of the directory containing the 
codejndex.fam directory, and 

• <home/.../code_index.xml> is the output xml file with the same full pathname as 
codejndex.fam. 

Reflectivity QC 

The AMU ran the WDSS-II QC tool, “w2qcnn”, for the KMLB and KMCO data sets. The 
WSR system has a routine that QC’s the reflectivity data in real-time and outputs both the raw 
and QC’d reflectivity. The AMU used the following command to QC the reflectivity data: 

w2qcnn -i <home/.../codeJndex.xml> -o </home/...> -u -R <gate spacing x beamwidth x range> 

where 

• <home/.../codeJndex.xml> includes the full pathname of the xml file created by 

replacelndex, 

• <home/...> is the same pathname for the directory containing the codejndex.xml file, 

• -u QC’s the data scan by scan, 

• -R for KMLB is “-R 0.25x0.5x460”, and 

• -R for KMCO is “-R 0.15x0.5x460”. 


Velocity De-aliasing 

The TDWR system has a de-aliasing algorithm and transmits both the aliased and de- 
aliased velocities, the latter called Conditioned Velocity, so this data set did not need to be de- 
aliased. The AMU de-aliased the KMLB data using the -D option in Idm2netcdf, which is the 
recommended method for de-aliasing WSR-88D data in WDSS-ll. The AMU also used the -D 
option in the Idm2netcdf command for the WSR data, but the values output were not correct. 
The WDSS-II developers recommend using the dealias2d tool with the data output from 
Idm2netcdf for non-WSR-88D radars. The AMU used the following input to dealias2d: 

dealias2d -i <home/.../codeJndex.xml> -o <home/...> 

where 

• <home/.../codeJndex.xml> is the input file including the full pathname of the xml file 
created by replacelndex, 

• <home/...> is the output directory, which is the same directory containing the 
codejndex.xml file, and 

• the ewtjable tile created by the Idm2netdf command for the KMLB data is copied into 
the same directory from which dealias2d is run. 

The results were similar to using the -D option in Idm2netcdf. A discussion of this issue with 
images is in section 3.2.2. Given this inability to properly de-alias the WSR data and other 
communication issues, the AMU did not use the WSR data in the dual-Doppler analysis. 

Data Display (Section 3.3) 

After processing, data from all three radars can be displayed in the WDSS-II GUI. The first 
step is to issue the wg command. Figure 5 in section 3.3 shows the initial display and describes 
the first few steps to load the data. 
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Initial Display 

After clicking the Browse... button in the initial dialog box, a new dialog box is displayed with 
a list of directories on the left and a list of files and directories in the highlighted directory on the 
right (Figure 2). The user navigates to the directory containing the codejndex.xml file of the 
radar data desired for display, clicks on the name of the file in the right column, and then clicks 
OK in the lower right. This closes the new dialog box and returns control to the initial dialog box 
(Figure 3). 


The full data path of the chosen data file is displayed in the URL text box in the New Source 
section of the initial dialog box. The user provides a name for the data set in the Name text box. 
In this case, the name is Feb12-KMCO, indicating the data are from KMCO during the 12 
February severe weather event (section 2.1). Using the default All in the History drop-down 
menu will load all the files in the directory. The drop-down list provides choices for the number 
of times to load. When all choices are made, the user clicks the Add button, and the Sources 
section in the control area is populated with information about the radar data, as in Figure 4. 
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r igure 2. The new dialog box displayed after clicking the 
Browse... button on the initial dialog box (section 3.3, Figure 5). 
The chosen directory is surrounded by the red box, the desired 
codejndex.xml file is highlighted in blue on the right side. 
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Figure 3. The initial dialog box (section 3.3, Figure 5) showing 
the chosen input file in the URL text box and the user-supplied 
name in the Name text box. 


The Sources section in Figure 4 displays the loaded radar data parameters to choose for 
display (compare with section 3.3, Figure 5). The left column contains the radar products such 
as velocity and reflectivity, the middle column contains the available elevation angles, and the 
right column contains the date and time of each scan. The user chooses the parameter, 
elevation angle and time to display. In this example, the QC’d reflectivity from the 0.3° elevation 
scan at 213527 UTC is displayed. 
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WG — NSSL/CIMMS Warning Decision Support System -Integrated Information GUI 
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r igure4. The WDSS-II display showing KMCO data on 12 February 2014 at 213527 
UTC. The Sources section displays the loaded radar data parameters to choose for 
display. The left column contains the radar products, the middle column contains the 
elevation angles, and the right column contains the time of each scan. 



Map Background 

Figure 4 lacks a map background. In the control area at the bottom of the GUI, click the 
Maps tab to view available maps. The initial setup contains one map named Earth that is similar 
to an out-of-focus Google Earth map. Figure 5 shows this map overlain with the same data as in 
Figure 4. This is obviously not desirable. A map background showing clear state and county 
borders would be more useful. 






-igure 5. WDSS-II with the map background that comes with the software. The data are 
the same as in Figure 4, but zoomed out. 

To get a map background with state and county borders, the AMU followed several steps 
found in the WDSS-II forum under the topic “Where to get background map shapefiles?”: 

• Created a directory named w2config in the home directory. 

• Created a directory named shapefiles in the new w2config directory. 

• In the shapefiles directory, created a directory for each type of map named states, 
Counties, and Cities. 
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• On website http://www.nws.noaa.gov/qeodata , downloaded the zipped files for the state, 
county, and city boundaries, and put them in their respective directories created in the 
previous step. 

• Unzipped the files within each directory. 

• Created a directory named maps in the w2config directory created in the first step. 

• Created a file named maps.xml (Figure 6) containing information about the shapefiles 
needed by WDSS-II. 

• Edited the .bashrc file in the home directory adding another directory path to the new 
w2config directory for the W2_CONFIG_LOCATION parameter. Appendix Figure 1 has 
this necessary addition. 


[x] wcra wford@doppler:~/w2config/maps - □ 


File Edit View Search Terminal Help 
<maps> 

<shp name='State' location='shapefiles/states/s_06sel2.shp' color='blue' /> 

<shp name= ' County ' location= ' shapef iles/Counties/c_03del3. shp ' color= ' green ' /> 
<shp name=' Cities' location='shapefiles/Cities/ci08aul2.shp' color=' white' /> 
</maps> 


(END) 


-igure 6. Contents of the maps.xml file in the w2config/maps directory. 

• Restarted the WDSS-II GUI and clicked on the Maps tab in the control area. 

• Clicked on the Add... button and chose a map by clicking on the name in the Add New 
Map dialog box (Figure 7). 

• Clicked Add in the lower right of the Add New Map dialog box. The dialog box 
disappears, the name of the new map file appears under Map Name in the Maps 
section, and the new map background is displayed (Figure 8). 



-igure 7. The Add New Map dialog box is displayed after clicking on Add... in the 
Maps menu. The State map is highlighted. 

The AMU added the state map, then the county map. The cities map was too busy and 
created a cluttered background to the radar data. To remove the Earth map display, the AMU 
clicked on Earth in the Map Name list and checked the Hide box to the left of Map Name in the 
Maps tab section. This left the state and county boundaries as the map background. To delete a 
map, click on the map then click the Delete button to the left of the Map Name list. 





-igure 8. The WDSS-II GUI displaying the state and county boundaries using the same 
data and zoom level as Figure 6. The Earth map is highlighted to show how to eliminate 
a map background without deleting it from the list by checking the box next to Hide in 
the Maps section. 

Choose Data to Display 

Section 3.3 of the report and Appendix Figure 2, Figure 3, and Figure 4 describe how to load 
and display one data set, specifically the 12 February 2014 KMCO QC’d reflectivity data at 0.3° 
elevation. Following the same procedure described in the Initial Display section above, more 
than one data set can be loaded in WDSS-II through the Sources tab. Figure 9 shows another 
tab added in the Sources content for KMLB data on 12 February. The highlighted product is the 
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0.5° ReflQC (QC’d reflectivity) at 213306 UTC, the time closest to the KMCO data in section 
3.3, Figure 6. 
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Figure 9. Similar to Figure 6 in section 3.3, except the Sources tab contains a seconc 
tab named “Feb12-KMLB”. The highlighted items in each list determine what is 
displayed: the KMLB 0.5° QC’d reflectivity at 213307 UTC. 


Once all three parameters of product, elevation angle, and time are chosen from one of the 
data source tabs in the Sources tab section, the data are displayed in the display area of the 
GUI, and the product is added to the text box in the Products tab section. Figure 10 shows the 
Products tab contents after choosing QC’d reflectivity and de-aliased velocity data from the 12 
February KMCO and KMLB data. Information about the data is in the top text box. The choices 
along the left side of the Products tab area allows the user to hide the data, show only the 
selected data (no overlay with other data), display range rings and azimuth lines, delete the data 
set, or choose a filter for the data. The text box to the right of this area shows the products that 





were chosen for display in the Sources tab. Note there are more than one. The area to the right 
of the text box controls which elevation angle and time is displayed. The forward (right) and 
backward (left) time buttons are outlined in red, and the upward (top) and downward (bottom) 
elevation angle buttons are outlined in green. The values of the next time forward or backward 
and of the next elevation up or down are displayed on the button. Since the lowest elevation 
angle of 0.5° is being displayed in Figure 10, the downward button shows the highest elevation 
angle of 19.5° from the previous volume scan. The buttons to the right if these display the last 
scan in the data set of the value shown on the button. The Display and Speed boxes below 
these controls allow the user to add a component of speed from a specific direction to the 
velocity data. 
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Figure 10. Similar to Figure 9, except for the de-aliased velocity at 213324 UTC and 
showing the Products tab contents. The buttons with a red box control the time 
displayed and the buttons with a green box control the elevation angle displayed. 



Data Merger Grid Setup (Section 4.1) 

The createCache tool must be run in the home directory. It creates a directory named 
.w2mergercache that contains the grid information accessed by the merger tools. The AMU 
used the following input to createCache for KMCO: 

createCache -i MCO -t “29 -81 .5 10” -b “27.5 -80.2 0” -s “0.009 0.009 0.5” -v “203 204” -verbose 

and for KMLB: 

createCache -i KMLB -t “29 -81 .5 10” -b “27.5 -80.2 0” -s “0.009 0.009 0.5” -verbose 

where 


• -i identifies the radar name, 

• -t defines the northwest corner lat/lon and top height in km of the grid, 

• -b defines the southeast corner lat/lon and bottom height in km of the grid, 

• -s defines the grid horizontal resolution in fractions of a degree and vertical resolution in km, 

• -v defines the VCP(s) used by the radar (not needed for WSR-88D radars), and 

• -verbose outputs verbose debugging information. 

Reflectivity Data Merger (Section 4.2) 

As stated in section 4.2, w2simulator must be started before w2merger. The AMU used the 
following input to w2simulator for the reflectivity merger: 

w2simulator -i “<home/...KMCO/code_index.xml> <home/...KMLB/codeJndex.xml>” 
-o <home/.../w2sim> -c -r 1 -b 20140212-2210 -e 20140212-2300 -verbose 


where 

• “<home/...KMCO/code_index.xml> <home/...KMLB/code_index.xml>” includes the full 
pathname of the xml files created by replacelndex for both radars, 

• <home/.../w2sim> is the directory for the w2simulator output, which can be any name 
chosen by the user, 

• -c processes only the times common to both radar data sets, 

• -r indicates multiples of processing speed, where 1 equates to real-time, 

• -b is the user-selected begin time of the data in the form YYYYMMDD-hhmm, 

• -e is the user-selected end time of the data in the same form as -b, and 

• -verbose outputs verbose debugging information. 

The elements -b and -e are not required, but are helpful to use when testing algorithms. A 
shorter time period takes less time to process and allows evaluation of the output sooner than 
processing the whole data set. 

Before hitting “Enter” to run the w2simulator tool, the AMU opened another terminal 
window on the Linux POC and typed the w2merger command line: 

w2merger -i “<home/.../w2sim/index_0.fam <home/.../w2sim/index_1 ,fam>” 
-o <home/.../w2mrg> -r -t “29 -81.5 10” -b “27.5 -80.2 0” -s “0.009 0.009 0.5” 
-I ReflectivityQC -C 7 -3 -p 0.5 -verbose 


where 


• “<home/.../w2sim/index_0.fam> <home/.../w2sim/index_1 .fam>” are the directories 
created by w2simulator, 

• <home/.../w2mrg> is the directory for the w2merger output, which can be any name 
chosen by the user, 

• -r indicates the algorithm is running in real-time even though it is an archived case, 

• -t, -b, and -s are as for createCache, 

• -I states to use the ReflectivityQC product as input (default is Reflectivity), 

• -C determines the way data values are combined if they overlap in space and time where 7 
is the default method, 

• -3 writes a single lat/lon/height grid with all the data, 

• -p is the round-off precision, and 

• --verbose outputs verbose debugging information. 

The AMU chose these elements for the w2merger command because they were recommended 
on the WDSS-II forum. 

Once both commands were typed in separate terminal windows, the AMU executed the 
w2simulator command. As soon as the text “You can start your algorithms now” displayed in 
the w2simulator window, the AMU executed the w2merger command in the other terminal 
window. 

The w2simulator command stopped and exited because it used .xml files as input, but the 
w2merger command did not exit since its inputs were the index_*.fam directories output by 
w2simulator (see Convert Idm2netcdf Output section above). When the w2simulator 
command had exited and the w2merger command had stopped, the AMU issued a Ctrl-C 
command in the w2merger window to force the command to exit. 

The w2merger output is a codejndex.fam directory that should be converted using 
replacelndex before displaying. Once converted, follow the directions outlined in the Data 
Display sections above. An example of the merged reflectivity field is shown in section 4.2 
Figure 11. 

Velocity Data Merger (Section 4.3) 

For the velocity merger, w2simulator must be executed again and run in conjunction with 
w2merger just as for the reflectivity merger. Before executing the commands below, run 
replacelndex on the home/.../w2mrg/code_index.fam directory following the directions in the 
Convert Idm2netcdf Output subsection in the Data Processing section above. The AMU used 
the following input to w2simulator for the velocity merger: 

w2simulator -i “<home/...KMCO/code_index.xml> <horne/...KMLB/code_index.xml> 
</home/.../w2mrg/code_index.xml>” -o <home/.../w2sim> -c -r 1 
-b 20140212-2210 -e 20140212-2300 -verbose 


where 

• “<home/...KMCO/code_index.xml> <horne/...KMLB/code_index.xml> 

</home/.../w2mrg/code_index.xml>” includes the full pathname of the xml files created 
by replacelndex for both radars as for reflectivity and the xml file from the w2merger 
reflectivity output, 
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• <home/.../w2sim> is the directory for the w2simulator output, which can be any name 
chosen by the user, 

• -c processes only the times common to both radar data sets, 

• -r indicates multiples of processing speed, where 1 equates to real-time, 

• -b is the user-selected begin time of the data in the form YYYYMMDD-hhmm, 

• -e is the user-selected end time of the data in the same form as -b, and 

• --verbose outputs verbose debugging information. 

The elements -b and -e are not required, but are helpful to use when testing algorithms. A 
shorter time period takes less time to process and allows evaluation of the output sooner than 
processing the whole data set. 

Before hitting “enter” to run the w2simulator tool, the AMU opened another terminal window 
on the Linux POC and typed the w2merger command line: 

w2merger -i “<home/.../w2sim/index_0.fam> <home/.../w2sim/index_1.fam> 
<home/.../w2sim/index_2.fam>” -o <home/.../w2mrg> -r -t “29 -81.5 10” 
-b “27.5 -80.2 0” -s “0.009 0.009 0.5” -I Velocity -C 8 -3 -p 0.5 -z 
MergedReflectivityQC:all -Z <home/.../w2mrg/code_index.xml> --verbose 

where 


• “<home/.../w2sim/index_0.fam <home/.../w2sim/index_1.fam> 

</home/.../w2sim/index_2.fam> ” are the directories created by w2simulator, 

• <home/.../w2mrg> is the directory for the w2merger output, which is the same as that 
for the reflectivity merger, 

• -r indicates the algorithm is running in real-time even though it is an archived case, 

• -t, -b, and -s are as for createCache, 

• -I states to use the Velocity product as input (default is Reflectivity), 

• -C determines the way data values are combined if they overlap in space and time where 8 
is the method for velocity mergers, 

• -3 writes a single lat/lon/height grid with all the data, 

• -p is the round-off precision, 

• -z identifies the reflectivity data type, 

• -Z is xml file containing the merged reflectivity, and 

• --verbose outputs verbose debugging information. 

The AMU chose these elements for the w2merger command because they were recommended 
on the WDSS-II forum. Due to the erroneous output as shown in section 4.3, the AMU tried 
other options and values that produced similar results. 

Once both commands were typed in separate terminal windows, the AMU executed the 
w2simulator command. As soon as the text “You can start your algorithms now” displayed in 
the w2simulator window, the AMU executed the w2merger command in the other terminal 
window. 

The w2simulator command stopped and exited because it used .xml files as input, but the 
w2merger command did not exit since its inputs were the index_*.fam directories output by 


w2simulator (see Convert Idm2netcdf Output section above). When the w2simulator 
command had exited and the w2merger command had stopped, the AMU issued a Ctrl-C 
command in the w2merger window to force the command to exit. 

The w2merger output is a codejndex.fam directory that should be converted using 
replacelndex before displaying. Once converted, follow the directions outlined in the Data 
Display sections above. 
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NOTICE 


Mention of a copyrighted, trademarked or proprietary product, service, or document does not 
constitute endorsement thereof by the author, ENSCO Inc., the AMU, the National Aeronautics 
and Space Administration, or the United States Government. Any such mention is solely for the 
purpose of fully informing the reader of the resources used to conduct the work reported herein. 


